The ever-increasing use of the Internet is changing the way many companies conduct business. In earlier years the primary use of the Internet was non-commercial and restricted to users with a high computer literacy. Increasingly, companies are promoting and selling goods and services to the general public via the Internet, and in many cases providing services on-line.
While the commercial use of the Internet still has enormous scope for expansion, it is still regarded with some trepidation by many consumers. Two issues of great concern are ease of use and the security of electronic transactions.
Because information and useful resources are distributed globally, an Internet user typically visits several web sites located on different servers in the course of a single on-line session. Problems arise when the user needs to interact with more than one site during a single commercial transaction. For example, site A, hosted on server A, is an on-line shop and site B, hosted on server B, is a Payment Gateway that validates payment information. The user selects and orders goods at site A, but provides payment details at site B. All relevant information entered by the user at site A should be available to the payment service at site B and, once payment has been approved, site A should be notified of this fact. The user should not have to enter data repeatedly (such as name, address and items selected) and the data should be kept secure at all times. There are several techniques currently available for transferring data between different servers, but they all have shortcomings.
The Hypertext Transfer Protocol (HTTP) used by the World Wide Web is a connectionless mechanism. Once a server has responded to a request from a browser, the connection between the browser and the server is broken and the server retains nothing of the browser user's session. Thus, if the user had filled out an address form and an order form and then requested access to another page, the information provided by the user would be lost on arrival at the new page. The known technique of ‘cookies’ effectively remembers a series of steps performed by the user and any data relevant to the next steps in a sequence of steps. However the cookies set by a server are valid for that server only and for no other. Thus if the user requires to move to a site on another server, information will be lost.
If two sites transfer information via some application logic, issues of security and synchronisation arise. Some known techniques are described with reference to FIG. 1. Here, an Internet user has access to the Internet 20 via browser software 10 running on the user's computer. Web sites requested by the user are displayed uniformly in the browser 10. Examples of browser software are MS Explorer™, supplied by Microsoft Corporation of Redmond, Wash., USA and Netscape Navigator™, supplied by Netscape Communications Corporation of Mountain View, Calif., USA. A plurality of servers 30, 32 connect to the Internet 20. For ease of depiction, only two servers are shown, but the actual number is of course far higher. Each of the servers 30, 32 hosts one or more web sites which may be accessed by the browser 10. The servers 30, 32 are able to communicate with one another via the Internet 20. In the configuration of FIG. 1, the first server 32 and the second server 30 are also connected by a proprietary Electronic Data Interchange link 40.
In a hypothetical example, site www.recruitdb.com, hosted on server 30, maintains a database of people with skills in Database programing, and site www.recruitjava.com, hosted on server 32 maintains a data base of people looking for jobs in the field of Java™ programing. A potential employer using the browser 10 accesses these web sites in search of suitable employees. An employer looking for programers in both Database and Java™ needs to search both sites separately. If however there is a cooperation agreement between the two sites, the potential employer should be able to do a combined search across the two web sites www.recruitdb.com and www.recruitjava.com. Known techniques for pooling resources in this way are to provide a common database or to share data between the two sites at the back office. Each of these techniques has its disadvantages. Providing a common database would require a redesign of the entire database schema and the software applications running on the two servers 30, 32.
Data sharing between the two databases may be done by regular data interchange (either via the Internet 20 or the EDI link 40) or by RMI/IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) or thirdly, by URL redirection. The data interchange may be done by XML or other means, but this approach would have synchronisation problems and would require a change of database schema and a modification of software on each of the servers 30, 32.
RMI (Remote Method Invocation) is a popular way of doing distributed programing in Java™ which exploits the object-orientated features of the Java™ language. RMI requires that the entire distributed application be programed in Java™, making use of the proprietary Java Remote Method Protocol (JRMP). RMI/IIOP extends this to an architecture supporting networks of distributed objects containing code written in more than one language. RMI/IIOP adopts the standards of CORBA (Common Object Request Broker Architecture), allowing a software object to communicate with other objects that support the CORBA standards. RMI/IIOP may be used to transfer data between servers 30, 32 but it requires additional coding at each of the servers 30, 32 and is not maintainable when the number of sites sharing data increases.
A third known method of data transfer between the servers 30, 32 is Universal Resource Locater (URL) redirection, in which a link on one of the servers 30, 32 forwards the user to the other of the servers 30, 32. A drawback of this method is that the user needs to provide credentials at both servers 30, 32. This is also an insecure way of transferring users between sites.
Another alternative method of transferring data between the sites 30, 32 is the Secure Electronic Transaction (SET) protocol, which deals with secure banking/credit card transactions over open networks. However, SET is used only for payments and not for general data transfer. SET has the disadvantage that users require additional client applications (called “wallets”). In addition, SET has large infrastructural requirements.
Another problem with the techniques outlined above is that application and third party products must be installed on each of the servers 30, 32 if they are to cooperate. There is no way in which, for example, server 30 can use an application installed at the server 32 unless suitable code is written and installed on both servers 30, 32. This introduces an additional cost and a potential source of software errors. This method requires software, and software certificates, to be loaded on multiple sites.
Any arrangement in which information passes between the user and a site on the server 30 via the server 32 as an intermediary represents a security risk and can have a detrimental effect on performance.
It is thus apparent that there is a need for an easy to use method of transferring information between a plurality of servers connected to the Internet, that preferably also is secure.